系統如何部署？應該使用甚麼工具部署？

目標系統通過功能與整體測試後，還要放入可以長期運作的執行環境。部署方案會限制可採用的作業系統、封裝方式、相依項目及更新流程，也會影響故障後能否在允許時間內恢復。

選擇工具前，應該先確認部署位置、管理責任、停機限制與復原要求，再決定部署單位及工具組合。工具可以協助建立與執行方案，無法代替這些條件判斷。

先確認部署環境與限制

部署環境會在程式完成前影響技術選擇。目標系統使用的語言、框架與相依項目如果無法在指定環境中安裝、啟動或維護，即使功能測試已經通過，也不能形成可用的部署方案。

開始設計前，應該將環境限制記錄成可確認的條件：

表格中的項目要按照實際系統刪減或補充。如果系統沒有網路互動，就不需要為它設計連線架構。如果系統不要求持續運作，也不必直接加入叢集（Cluster）或自動擴充機制。

將部署需求改寫成可驗收條件

「容易部署」或「具備高可用性」無法直接驗收。部署需求應該包含可觀察的情境、限制值與通過條件，讓候選方案可以使用相同基準比較。

資料備份與版本還原處理不同問題。備份用來復原保存資料或設定，版本還原則把程式及相關設定切回已知可用狀態。兩者都要實際演練，不能因為已保留檔案或版本名稱就視為可以復原。

確認真正的部署單位

部署單位是可以獨立建置、版本化、啟動、停止及更換的程式集合。它不一定等同於程式碼中的模組，也不代表每個功能都要獨立部署。

如果多個程式必須永遠一起發布、共同停止，而且無法獨立驗收，把它們拆成多個部署單位通常只會增加協調工作。相反地，已確認具有不同更新頻率、擴充需求或失敗範圍的項目，才適合評估獨立部署。分散式架構的判斷與互動設計會由後續章節繼續說明。

分清部署工具的責任層次

部署方案可能同時使用多種工具。虛擬化平臺建立隔離的執行環境，容器引擎負責建立及執行容器，容器編排工具維持多個容器化工作負載的預期狀態，自動化流程工具執行檢查與部署步驟，基礎設施即程式碼則描述並管理環境資源。

先確認缺少的是哪一層能力，再加入相應工具。工具之間可以組合，但每多一層就會增加版本相容、更新、監控、存取限制與故障處理責任。

虛擬機管理工具

虛擬機適合需要完整作業系統隔離、既有執行方式難以容器化，或正式環境已經採用虛擬化管理流程的情境。選擇時要比較現有環境相容性、集中管理、備份、遷移、自動化介面、授權與支援方式。

vCenter 是 vSphere 環境的集中管理元件，不能單獨視為所有虛擬機方案的共同工具。候選方案如果依賴特定管理平臺，概念驗證也要包含該平臺的建立、更新與復原流程。

容器與容器編排工具

容器（Container）將程式、必要相依項目及預設執行資訊封裝成可重複使用的映像檔。它可以減少環境差異，但仍要處理映像來源、更新、保存資料、連線、執行限制及敏感設定。

Docker Compose 與 Kubernetes 的管理範圍不同。Compose 適合描述多容器應用程式，Kubernetes 則持續調整工作負載，使實際狀態接近宣告狀態。容器數量少或不需要叢集能力時，Kubernetes 增加的控制元件與維運工作未必能帶來相應價值。

持續整合與持續部署工具

持續整合與持續部署（Continuous Integration and Continuous Deployment, CI/CD）工具可以把檢查、建置、測試與部署步驟寫成可重複執行的流程。本章只比較工具與部署環境的適配性，流程觸發、成品管理、核准與自動部署會由後續章節說明。

GitHub 與 GitLab 是協作平臺，表格比較的是其中的 GitHub Actions 與 GitLab CI/CD。無論採用哪一項工具，執行器都要能在符合存取限制的前提下到達部署環境。把正式環境的廣泛存取能力長期放在一般建置流程中，會擴大流程遭誤用或受影響時的範圍。

基礎設施即程式碼工具

基礎設施即程式碼（Infrastructure as Code, IaC）以可版本化的程式或設定描述環境資源。它能讓建立與變更流程重複執行，也能在套用前顯示預計異動。採用 IaC 時，仍要管理狀態、敏感資訊、變更核准及工具本身的版本。

比較 IaC 工具時，不能只確認是否能建立第一個環境。還要以現有資源匯入、設定漂移、部分套用失敗、Provider 升級、狀態遺失及資源刪除等情境驗證生命週期。計畫畫面也需要人工或自動規則檢查，避免未預期的替換與刪除直接進入正式環境。

從限制推導工具組合

工具選擇應該能說明「哪一項限制導致哪一個決定」。下列情境只用來示範推導方式，不能直接當成所有系統的標準答案：

• 如果正式環境已有受支援的虛擬化平臺，而且目標程式需要完整作業系統環境，可以先驗證虛擬機方案，不必先增加容器層。
• 如果目標程式適合封裝成容器，而且只包含少量固定相依項目，可以比較 Docker Engine 或 Podman，並視多容器管理需要評估 Docker Compose。
• 如果已確認多個部署單位需要在叢集內接受調度、獨立擴充及故障替換，可以評估 Kubernetes，並把叢集本身的維運成本納入方案。
• 如果測試、預備與正式環境需要反覆建立相同資源，可以評估 IaC，並先確認目標平臺具有受支援的 Provider 或管理介面。
• 如果發布頻率與稽核要求需要可重複流程，可以在既有協作平臺上評估 GitHub Actions 或 GitLab CI/CD，並限制執行器及部署環境的存取範圍。

程式語言、框架與資料保存方式也要回到部署限制重新檢查。候選技術必須能在指定作業系統與執行方式中受到支援，具備可接受的建置與啟動時間，並且能讓維運人員完成更新、觀察、備份及故障處理。如果系統包含資料庫、訊息系統或其他保存型相依項目，還要分別確認其部署、升級、一致性與復原方式。

透過概念驗證確認可行性

文件中的功能清單只能協助縮小候選範圍。高風險差異應該使用概念驗證（Proof of Concept, POC）取得實際結果。POC 可以選擇一個最小但完整的部署單位，完成下列工作：

• 從乾淨環境按照已記錄步驟建立所需資源。
• 建置並部署指定版本，確認成品、設定與環境可以對應。
• 啟動程式並執行最小健康檢查及關鍵功能測試。
• 模擬建置失敗、啟動失敗、更新中斷及相依項目暫時無法使用。
• 執行版本還原或向前修正，並確認保存資料維持預期結果。
• 記錄建立時間、部署時間、中斷時間、人工步驟、錯誤資訊與復原結果。
• 由實際維運人員按照文件重新執行，確認操作與調查成本可以長期負擔。

POC 要使用正式方案會採用的關鍵元件與限制，但不需要先建置完整正式環境。驗證結果不符合門檻時，應該修改方案或選擇其他候選工具，不能只把失敗步驟留給正式部署時處理。

使用架構決策紀錄保存選擇

完成比較與 POC 後，使用架構決策紀錄（Architecture Decision Record, ADR）保存選擇，讓後續人員知道這項決定適用的條件及重新評估時機。

ADR 應該連回部署需求與 POC 結果。只寫「採用 Kubernetes」或「使用 Docker」無法說明工具為何適合，也無法在條件改變時判斷是否需要調整。

完成部署方案的檢查

進入實際部署流程前，可以使用下列問題確認方案：

• 部署位置、作業系統、執行資源、輸入輸出、存取限制及規範要求是否已經確認？
• 停機、發布頻率、可用性、擴充、備份、災難復原及失敗處理是否具有可驗收條件？
• 每個部署單位是否能獨立建置、版本化、啟動、停止、更新及驗證？
• 虛擬化、容器、多容器定義、容器編排、CI/CD 與 IaC 工具的責任是否已經分清？
• 候選工具是否支援指定環境，並且具有可接受的更新、授權、支援及維護方式？
• 執行器與自動化流程是否只取得完成工作所需的存取範圍？
• 保存資料、設定與程式版本是否分別具有可執行的復原方式？
• 高風險部署、更新及失敗情境是否已經完成 POC 並留下結果？
• ADR 是否記錄限制、候選方案、取捨、維護責任及重新評估條件？

重點整理

• 部署方案要先確認執行環境、管理責任、資料限制與維運能力，再將停機、可用性、擴充及復原需求改寫成可驗收條件。
• 部署單位可能是單一應用程式、模組化單體、多個服務或背景工作。只有已確認獨立發布、擴充或故障範圍時，才需要增加獨立部署單位。
• vSphere 與 vCenter、Hyper-V、Proxmox VE 提供不同的虛擬化管理方式，選擇時要配合現有環境、支援、授權及復原能力。
• Docker Engine 與 Podman 是容器引擎，Docker Compose 負責描述多容器應用程式，Kubernetes 則管理容器化工作負載的預期狀態。
• GitHub Actions 與 GitLab CI/CD 執行自動化流程，Terraform、OpenTofu 與 Pulumi 管理可由程式描述的環境資源。這些工具各自處理不同層次。
• POC 應該驗證建立、部署、更新、失敗及復原情境，ADR 則保存限制、比較結果、最後選擇、已知代價與重新評估條件。